Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES

--000e0cd297bcbb5145046a8600cb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Fri, May 22, 2009 at 2:59 PM, William A. Rowe, Jr.
wrote:

> Joe Orton wrote:
> >
> > Having thought about this longer, I do agree that it would be reasonable
> > to provide OPT_INCNOEXEC as a noop integer for back-compat, but, it
> > turns out we're out of bits - allow_options_t is an unsigned char and
> > we're using 2^0 through 2^7 already. :(
>
> The C langauge promotes char -> int for comparison. 256 should work fine,
> no? It would devolve to 0, of course, but 256 & 255 should test fine.
>
> Thoughts?


Backing up a bit...

I originally thought we could map bit values in 2.2.x to avoid affecting
modules, but that isn't possible since includes-with-exec is two bits
instead of one.

Mapping OPT_INCNOEXEC to a no-op integer is something that takes place at
compile time, and helps applications which reference the symbol but don't
use it in any important way. (IOW, let mod_perl and other similar tarballs
compile.) It is good in that it lets mod_perl compile, but bad in that
mod_perl continues to export the Perl mapping of OPT_INCNOEXEC even after
httpd has been upgraded and at some point later mod_perl is upgraded.

Failing the compile is our only opportunity to catch some affected modules
(though it is a rather late opportunity since the modules will likely be
rebuilt later since they're supposed to work as-is when upgrading httpd;
somebody will grumble though).

I don't think we should try to preserve compilability if we can't preserve
compatibility.


>
> > The only available option is to #define OPT_INCNOEXEC to some bogus
> > string or something; not sure I like that much better than just a clean
> > break.
>

/*
* #define OPT_INCNOEXEC 32
* Apache 2.2.12 and later no longer provide this.
* Applications which distinguish between includes-without-exec and
includes-with-exec
* must use different logic for 2.2.<12 and 2.2.>=12.
* Prior to 2.2.12:
* includes-without-exec: OPT_INCNOEXEC flag on, OPT_INCLUDES flag off
* includes-with-exec: OPT_INCNOEXEC flag off, OPT_INCLUDES flag on
* As of 2.2.12:
* includes-without-exec: OPT_INCLUDES flag on, OPT_INC_WITH_EXEC flag off
* includes-with-exec: OPT_INCLUDES flag on, OPT_INC_WITH_EXEC flag on
*
*/

--000e0cd297bcbb5145046a8600cb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules

Jeff Trawick wrote:
>
> Backing up a bit...
>
> I originally thought we could map bit values in 2.2.x to avoid affecting
> modules, but that isn't possible since includes-with-exec is two bits
> instead of one.

Hold on... I think this can still work;

* Retain new true 'Includes' bit as old IncludesNoExec macro value
Keep ancient Includes flag bit as 256, never true.

- all httpd modules testing for including but not executing
permission see the permission as allowed

- old httpd modules testing for includes with exec permission
see the permission as denied, until they update the module

- httpd modules which force/override the includes without exec
permission would still work

- httpd modules which force/override the includes exec behavior
would just fail to update anything (256 & 0xff == 00), so it
becomes a noop until they update the module

So it has no negative security consequences, still would require
an update to the rare module, but lets us ship something without
really nasty side effects.